Ramon Lopes

Certo... bem pensado... Acho que vamos adotar procedimento semelhante - isso resolvera a questao. Valeu!

hehehe... da uma olhadinha melhor, esta sim... O relatorio eh extenso mas tem isso com toda certeza.

Segundo o novo roteiro, precisaremos tirar uma "foto" da posicao do estoque no momento da abertura do dia, que eh considerado o momento em que o primeiro documento (fiscal ou nao fiscal) for impresso em um dos ECFs do estabelecimento. A duvida eh... o que significa "impressao"... o horario de impressao no cabecalho, ou o horario que finalizou o cupom (rodape do cupom)... Pergunto pois dependendo da informacao, podem ocorrer situacoes distintas... Imagine um mercado com 10 ECF, o ECF005 que abriu as 07:28 e esta passando um rancho de 150 itens.. o que vai levar digamos 5 minutos (vai encerrar o seu primeiro cupom as 07:33). Porem, o ECF002 abriu pontualmente as 07:30 e vendeu 1 item apenas, finalizando seu primeiro cupom as 07:30:53... com isso ele foi o primeiro a "tirar a foto do estoque", mas nao foi o primeiro documento impresso no dia - o primeiro foi o cupom iniciado as 07:28:00 e finalizado as 07:33....

Acabei de conferir com eles... pode deixar SIM/NAO.

Segue em anexo o relatorio no novo formato especificado na ER0109 Homologador da Polimig/MG deu o OK.

Acabei de conversar com o Deynison, da Polimig/MG - realmente pode ser em cascata, desde que seja evidenciado o item que foi alterado, e que nao "sumam" registros qdo alterado o serial, coo, crz, etc.... tranquilo.

Ola Juliomar... Acontece que ao alterar o R01 por exemplo, automaticamente se alterariam as chaves de R02,R03,R04.... pois seria em cascata.... a principio essa seria a duvida. Assim que tiver uma resposta da polimig eu posto aqui.

Me ocorreu outra solucao: Colocar as chaves FK com a regra de "ON UPDATE CASCADE", isso resolveria tudo... so que alteraria em cascata em todos os "R"s nao sei se isso seria permitido, se for esta resolvido... Acabei de mandar um email ao homologador e vou ligar cedinho p ele, depois posto aqui.

Vou fazer o seguinte: vou duplicar os campos chave ex: CRZ: vai ter uma coluna chamada CRZ e outra chamada REDZ_KEY. Na query p homologar, usarei CRZ, e nas ligações uso REDZ_KEY. Só vou tomar o cuidado de gerar o arquivo com a coluna alterada, p poder passar no teste.

Olá. Preciso de uma idéia. Estou Me debatendo com o arquivo de movimentos por ECF. Ocorre que nos testes precisamos manipular os campos que servem de chaves PK/FK. Exemplo: se eu mudar o CRZ perco a ligação com os cupons dessa ReducaoZ. Como vcs tem contornado isso?

No teste 115, ao apagar ou incluir novo DAV, devo preencher com ??? os espaços disponiveis na RazaoSocial - campo 5 do registo D1. Como vcs estao procedendo caso a RazaoSocial do estabelecimento tenha mais de 50 caracteres? Exemplo: AMENITA DISTRIBUIDORA DE UTILIDADES DOMESTICAS E BAZAR LTDA = 59 CARACTERES. Atualmente estou truncando, deixando apenas os primeiros 50 caracteres.. no caso de preencher com ?, eu adiciono as interrogacoes no meio de cada palavra, ou tiro mais 3 ou 4 digitos... exemplo: AMENITA?DISTRIBUIDORA?DE?UTILIDADES?DOMESTICAS?E?B ou AMENITA DISTRIBUIDORA DE UTILIDADES DOMESTICAS????

Tranquilo.. vou fazer na mao entao, pois na pre-homologacao isso foi apontado como erro. Na realidade poderiamos ter utilizado os 13digs, mas optamos por ficar com 10 pelo espaço em tela, etc... Fica a sugestao para futuras implementacoes... Eu infelizmente nao tenho conhecimento de como se faz.

Ola Estou imprimindo o relatorio de DAV Emitidos, pelo comando: ACBrECF1.PafMF_RelDAVEmitidos() O numero esta saindo com 13 digitos, mas adotamos o padrao de utilizar apenas 10 em nosso aplicativo. Tem alguma maneira de contornar isso?

Regys, eu estava fazendo o relatorio de parametros de config na mao, pois nao tinha visto isso.... Se voce achar que isso libera antes desta segunda-feira, eu aguardo, senao eu finalizo na mao, pois minha homologação eh semana que vem....

Fizemos uma leitura detalhada e desprezamos o que dizia respeito a pedagio, posto de combustivel, farmacia de manipulacao e bares / restaurantes, que nao sao atividades cobertar pelo nosso aplicativo... notamos as seguintes mudancas: Req.VI - Item 8 (DAV) - Pelo que interpretamos, passa a ser possivel a inclusao de itens em DAV impresso na nao fiscal (vamos confirmar com o homologador, mas o termo que foi acrescentado dá a entender isso. Req.VII - Item 8 (Menu Fiscal / Estoque): Deixa claro que a data do movimento do estoque, nao eh mais o encerramento de ontem, e sim a abertura de hoje, exigindo a captura da data+hora do primeiro documento impresso em ECF no estabelecimento (fiscal ou nao fiscal) - no meu caso sera a principal mudanca de logica que notamos Req.VII - Item 19 (Menu Fiscal / Vendas do Periodo): Acrescentou algumas palavras no meio do texto "EMITIDAS PELO PAF-ECF EXCLUSIVAMENTE", ainda nao conseguimos entender que impacto teria isso, mas vamos ligar para o homologador durante o dia para confirmar. Req.VII - Item 21 (Menu Fiscal / Parametros de configuracao): Acrescentou algumas regras de como fazer o relatorio. Req.VIII - Item 2 (Acrescentou uma frase: DEVIDAMENTE CONSISTIDO) ao CPF/CNPJ Req.VIII-A - Acrescentado o item 2A (Cupom Mania) Req.XXVIII - Corrigiram o caso de imprimir o MD5 no campo reservado ao fisco, e inclusive grifaram NO CAMPO DADOS ADICIONAIS. hehehe As demais mudancas que anotamos aqui sao as que o ACBR ja se antecipou, que tem a ver com a geracao dos arquivos: D3, incluiram o campo de Sit.Trib, Aliquota, Casas decimais, etc... E1 - inclui os dados do ECF que atualizou o estoque (campos 6,7,8,9,10) e acrescentou data e hora da atualizacao do estoque (11 e 12) E2 - Eliminaram a data do estoque. Basicamente o que anotamos como mudancas de um roteiro para o outro foi justamente isso. Ja estamos trabalhando pois a homologacao sera na semana que vem e ja vamos homologar na 01.09. Abraço a todos e sucesso.

Preciso colocar a geracao de arquivo da NFPaulista no PAF, ou os arquivos gerados no menu fiscal substituem? Caso eu tenha por exemplo 5 ecfs na empresa onde o sistema esta instalado, tenho que gerar um arquivo para cada ECF, ou eh um arquivo so com tudo junto? Outra duvida eh sobre a geracao do arquivo, tem algo que auxilie na ACBR, ou tenho que ler da impressora, alguem sabe como isso funciona?

Valeu Isaque.. O que aconteceu: Peguei o projeto andando, o programador que fazia o PAF saiu da empresa e peguei a coisa andando. realmente esta desatualizado, vou atualizar agora mesmo e revisar tudo de novo... Faz parte. Desculpe a amolaçao e mto obrigado pela ajuda.

Gerei o arquivo de DAVs emitidos seguindo o exemplo do componente ACBRPAF. Gerou registros D1, D2, D3, D9 / EAD. Estou revisando o sistema, e percebi que o bloco D3 simplesmente nao existe no ato cotepe... Algum motivo em especial para este registro estar no exemplo e no proprio componente? Posso gerar o arquivo com ele, ou nao devo?

Pois eh, achei meio absurdo replicar os dados de volta p estacoes... Fico imaginando um determinado cliente que tenha 50 ECF operando simultaneamente, imagina jogar todos os dados no servidor e depois puxar tudo de volta p estacoes... Mesma coisa com as NFEs, etc etc... Nao tem como. Mandei uma pergunta p orgao tecnico para verificar o que fazer. Depois que tiver algo mais consistente eu posto aqui. Tnks.

No meu caso, utilizo os DAVs gravados no banco de dados do servidor, nao consigo gerar o arquivo (nem o relatorio) de davs emitidos por exemplo. Outro exemplo eh o arquivo de vendas do periodo. Se pegar um periodo mais antigo (digamos 3 meses atras) nao consigo dar a posicao do estoque (blocoH), nem a apuracao do ICMS (BlocoE). As vendas de outros ECFs tmb nao apareceriam, nem as notas eletronicas emitidas (pois estao centralizadas no servidor).

No bloco H, devo informar os produtos que tenham o saldo zerado em estoque? E os que porventura estiverem constando como estoque negativo, devem aparecer ou somente os que tiverem quantidade na data do arquivo?

Como deve se portar o menu fiscal no caso de nao ter rede disponivel. Pergunto isso especificamente em relacao a opcao dos arquivos de vendas do periodo (sintegra + sped) devo gerar mesmo offline? nesse caso como ficariam as informacoes de nfe + nota manual,e tc....

Descobri a solucao. Pesquisando no fonte do componente, percebi que bastava setar "IND_PROC := opNenhum;" com isso o indicador de processo fica nulo dentro do arquivo. Sugestao: Poderiamos atribuir essa opcao como padrao caso nao seja declarado, ele ao inves de pegar zero (0= sefaz), pegaria o opNenhum (nulo).

Pelo que entendi, devo gerar o registro "C460 - Documento fiscal emitido no ECF (Cupom)" para todos os cupons emitidos - inclusive os cancelados. Fiquei na duvida sobre "C470 - Itens do cupom" e "C490 - Registro Analitico do Movimento diario" para os casos de: cupons cancelados, e itens cancelados no cupom.

Estou gerando o RegistroE116, porem nao estou informando o NUM_PROC (pois nao eh aplicavel ao meu caso), porem o validador esta dando a seguinte mensagem de incosistencia: "Se for preenchido o numero do processo ou ato concessionario (NUM_PROC) deverão também estar preenchidos os campos Indicador de Origem do Processo (IND_PROC) e Descricao resumida do processo (PROC). Caso contrario nenhum dos campos deverão estar preenchidos". Pelo que percebi, tem um zero no campo ORIGEM DO PROCESSO, que nao foi informado por mim, penso que o componente esteja arbitrariamente preenchendo. Segue a linha gerada no arquivo do SPED, que esta dando o erro: |E116|000|79,02|25102011|000||0|||092011|